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Be s chr e ibung 

Verfahren und Anordnung zur kundenseitigen Anpassung von 
Software 

Die Erfindung betrifft ein Verfahren und eine Anordnung zur 
Transformation von Software, bei dem/der eine Software, in 
eine Darstellung in einer Meta-Auszeichnungssprache, 
beispielsweise XML, ubergefUhrt, dort, beispielsweise mit 
XSLT, transformiert und dann diese in der Meta- 
Auszeichnungssprache formulierte transformierte Darstellung 
in eine modif izierte Software, beispielsweise derselben 
Aus gangs spr ache, zurUckverwandelt wird. 

Aus dem Internet ist unter http://beautvi.berlios.de/ ein 
Java Source Code Transformation Tool BeautyJ bekannt, bei dem 
em Java Quellcode in eine XML-Darstellung umgewandelt wird, 
mittels Sourclet API, beispielsweise durch Einftigen von 
Leerzeichen oder geanderten Kommentaren an bestimmten 
Stellen, „versch6nert' und anschlieBend der modifizierte 
Quellcode in Java Quellcode zurtick konvertiert werden kann. 
Eine Transformation mittels XSLT wird hier, ftir diesen Zweck, 
nur vorgeschlagen, aber nicht umgesetzt. 

Die der Erfindung zugrunde liegende Aufgabe liegt nun darin, 
ein Verfahren und eine Anordnung zur Modifikation von 
Quellcode anzugeben, bei dem/der eine weitergehende noch 
flexiblere und effizientere Modifikation der Quellcodes 
erreicht wird. 

Diese Aufgabe wird hinsichtlich des Verfahrens durch die 
Merkmale des Patentanspruchs 1 und hinsichtlich der Anordnung 
durch die Merkmale des Anspruchs 6 erf indungsgemaB gelost. 
Die weiteren AnsprUche betreffen bevorzugte Ausgestaltungen 
der Erfindung. 



Dxe Erfindung besteht im Wesentlichen darin, dass ausgewahlte 
Bestandteile einer Software, Klassen und/oder einzelne 
Fragmente, als Variationspunkte VP dienen kannen, indem diese 
m emen in einer Meta-Auszeichnungssprache formulierten 
ersten Code (CodeML) umgewandelt werden, die Software nun in 
Mischform, d.h. kompilierter Code und CodeML, ausgelierf ert 
ward> und der erste Code CodeML kundenseitig durch eine oder 
mehrere Transformationen T, bspw. XSLT, nur in Abhangigkeit 
von Transformationsregeln TR, die Modif izierungsregeln ftir 
dxe Variationspynkte VP enthalten, in einen in der Meta- 
Auszeichnungssprache formulierten zweiten Code CodeML* 
umgewandelt werden kann und dieser zweite Code wiederum 
gleich als Variationspunkt oder in kompilierter Form die 
Abarbeitungsreihenfolge und/oder das Verhalten der Software 
verandert, woraus folgt, das sich die erste und die zweite 
Software an den Variationspunkten unterscheiden. 

Die Erfindung wird im Folgenden anhand des in Zeichnung 1 " 
darges tell ten Beispiels naher erlautert. Dabei zeigt 

I 

Zeichnung 1 ein Gesamtblockdiagramm zur Eriauterung der 

Erfindung. 

in Zeichnung 1 ist ein Gesamtblockdiagramm zur Eriauterung 
der Erfindung dargestellt, bei dem zun^chst eine Software SW 
bestehend aus Quelltext SCI, SC2 und SO in eine 
auslieferungsfShige Software SW* umgewandelt wird, wobei 
einige Telle der, Software wie bspw. SCI nun als 
Binarcode/Byte Code Bl zur VerfUgung stehen, und andere Telle 
wie bspw. SC2 durch einen Konverter CONV in einen in einer 
Meta-Auszeichnungssprache formulierten ersten Code CodeML 
umgewandelt werden, so dafi sie in der lauffahigen Software 
SW* fortan Variationspunkte VP bspw. VPI bilden. Diese 
software SW* kann vor/oder zur Laufzeit auf eine Weise 
modifiziert werden, das der in der Meta-Auszeichnungssprache 
dargestellte Code VP, bspw. VP2, mit einer Transformation T 
und Transformationsregeln TR in einen zweiten in der Meta- 
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Auszeichnungssprache formulierten Code CodeML* umgewandelt 
wird, welcher nun entweder als geanderter Variationspunkt 
bspw. VP2* in SW* vorhanden ist oder durch einen Konverter 
RCONV nach der Transformation T in einen Quellcode SC* und 
danach mittels COMP in einen ByteCode/Binarcode VP2B* 
Uberftihrt wird. In beiden Fallen unterscheiden sich SW und 
SW* an den Stellen der Variationspunkte und kOnnen auf diese 
Weise an spezifische Anforderungen (bspw. Tookit-Austausch, 
Updates, usw. ) angepasst werden. 

Die Codes CodeML und CodeML* bzw. VP und VP* sind 
beispielsweise in der Meta-Auszeichnungssprache XML 
formuliert, wobei ^XML'^ fUr Extended Markup Language steht. 

Von besonderem Vorteil ist hierbei, dass dies nicht vom 
Programmentwickler durchgefUhrt werden muss, sondern vom 
entsprechend ausgestatteten und informierten Kunden selbst 
erledigt werden kann. Hierzu braucht ein Operator oder 
Administrator auf der Kundenseite nur eine entsprechende 
Transformation T mit den benStigten Ersetzungs-, 
Modifikations- und Entf ernungsregeln TR anzuwenden, urn die 
Software auf seine speziellen Bedurfnisse anzupassen bzw. ein 
Update Oder Patching durchzufUhren. Beim Update oder Patching 
von kundenspezifisch angepasster treten bislang haufig 
Probleme wegen Inkonsistenzen auf, die durch diese Erfindung 
und die MOglichkeit der Pipelineanwendung bzw. geordnete 

Hintereinanderausftlhrung von Anfang an vermieden werden 
konnen . 

Die im Anhang befindlichen Programmauf listungen Listing 1 bis 
Listing 5 zeigen dies an einem konkreten Beispiel: 
Typischerweise kann eine Sof tware-Auslief erung an zwei 
unterschiedliche Kunden unterschiedliche Toolkits verwenden, 
die sich hinsichtlich Performance, Preis usw. unterscheiden. 

So soil hier ein Code der ursprttnglich eine 
Registrierungsklasse 
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import electric. regis try. Registry 

aus einem Glue-Toolkit verwendet, beim zweiten Kunden nun 
zwex neue "Registrierungsklassen" 
import org. apache. axis. client. Call und 

import org. apache. axis. client. service aus einem Axis-Tookit 

verwenden . 

In XSL kann dies z.B. mittels 

<xsl : template match="import"> 

<xsl:if test="dot/name« • Registry 
<import> 

<dot> 

</<lot> 
</iinport> 
<linport> 

<dot> 



</import> 
</xsl:if> 

<xsl : i f t es t«"do t/ name ! - • Registry » " > 

<xsl : copy-of s elects" . "/> 
</xsl:if> 



ot> 



</xsl:teinplate> 



geschehen. Schablonen bzw. Templates warden in XSL auf das in 
match definierte Muster angewendet. Das import-Template im 
Listing-Beispiel also auf alle ursprUnglichen import- 
Anweisungen. im konkreten Beispiel ignoriert es einfach alle 
ursprunglichen GlUE-Registry-lmports, und fUgt stattdessen 
die zwei Axis-spezif ischen imports ein. 

Durch das erfindungsgemafie Verfahren ergeben sich noch eine 
Reihe von zusatzlichen Vorteilen, wie beispielsweise: 

1. Es ist nur ein System ftir Problemstellungen wie Patching, 
customizing. Updating, etc. erforderlich und nicht eine Reihe 
verschiedener teilweise proprietarer Werkzeuge. 

2. Das Verfahren basiert auf Standards wie XML und XSLT und 
ist hinsichtlich der Konvertierbarkeit in andere 
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andere Verf ahren zur Modif ikation von Quellcode . 
s K'n'^^r^.""' toaplizierte Quellcode- 

Standards w.e XSLT, xPath und XQuery genutzt warden. 

0 h;^'"'"! '^'' ^^'^ Modifitetlon erlaubt die Erstellung von 
0 Hxerarchren u.a. duroh die MOglichkeit zur geordneten, 

Trin'Ii^rr!" ^"hrung (Pipelines, .ehrerer 

iransformationen, bspw. von Patches. 



5. Die Iransformationen konnen fUr eine allgemeine 

Bibl^rrr"''""' XSLT-Dateien gespeichert werden, so daB 
Brblxotheken z.B. far besti-^te «,lMufe entstahen k5nnen. 

^-DaHa''" '^^-^^^"-''tation das Quellcodes in einer 

Datenbasxs gespeichert und bei Bedarf mit Hiife einer 
XSLT m exnfaoher Weise an die jaweiligen KundenbedUrfnissa 
angepasst werden (Customization) . aurrnrsse 

7. Duroh die Verwendung der Standards XMLSchama Oder did odar 

auf be":f T l"""' Ko^^iiierung, , 

warden «°-e>cthaitsaspekta hin, uberprUft <validie!t, 

8 Obliohe XMl-Tools lc6nnen zur einfaohen Bearbaitung bzw. 
Visualisierung und Bestimmung von Beziehungen im Code 
verwendet werden. 

9. Dauerhafte XML-basiarte Programmbibliotheken, die XPath- 
Anfragen unterstutzen, kennen die Miedervarwendung von code 

Oder Ta^l'a't" ''"'k'"'" ""^'^ code-rrag^entan 

oaer Templates verbessert werden. 
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Anhang : 



Listing 1: TestRegistry . java 

import electric . registry. Registry; 
public class TestRegistry 

^ //weiterer Quellcode in dem etwas geandert werden muss 

Listing 2: TestRegi5try.xjava 

<?xml version-"!. 0" encoding="UTF-8"?> 
< j ava> 

<in^rt> 
<class> 

<modlfiers><public/></modifiers> 

<name>TestRegistry</name> 

<block> 

<block> 
</class> 
</ j ava> 

Listing 3: VariationPointTl . xsl 

*** copy template 
***♦*♦♦**♦**♦ 4, ^^^t^j^.^^ ^ 

<xsl : template match=:"*"> 

<xsl : copyXxsl : apply-templates/X/xsl : copy> 
</xsl : tempi ate> 

*** Variotion Point Transformation 1 ** 

<xsl: template match«"import"> 

<xsl : if test="dot/name« » Registry* "> 
<import> 
<dot> 

<name>client</name></dot><name>Call</name> -i.s^/name^^/aou> 

</dot> 
</import> 
<import> 

<dot> 

</dot> 
</ import > 
</xsl:if> 

<xsl : if test="dot/name I « » Registry » "> 

<xsl:copy-of select=".»V> 
</xsl:lf> I. 

•ft* 

</xsl:template> 
</xsl : stylesheet> 

Listing 4: TestRegistry. xjava (*) 



<7xml version="a.O" encoding="UTF-8"?> 



<j ava> 
<impori:> 
<dot> 

<name>client</name></dot><name>Call</nam8> name^^/aot^ 
</dot> 

</iinport> 

<±mport> 

<dot> 

<name>client</naine></dot><name>Service</name> / imme^^/aotj' 

</dot> 
</lraport> 
<cla8s> 

<raodifiers><public/></inodifiers> 
<n a me>Tes t Regl St r y</ name> 
<block> 

<block> 
</class> 
</java> 



Listing 5: TestRegistry.java (*) 



import org. apache. axis. client. Call; //Axis 
import org. apache . axis . client . Service; 
public class TestRegistry 

... //weiterer Quellcode in dem etwas geSndert wurde 
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Patentansprtiche 

1. Verfahren zur kundenseitigen Anpassung von Software, 

- bei dem eine erste Software (SW) bestehend aus Quelltext SC 
in eine lauffahige zweite Form (SW*) bestehend aus in einer 
Meta-Auszeichnungssprache formulierten Variationspunkten VP 
und/oder kompilierten ByteCode bzw. Binarcode B umgewandelt • 
wird, 

- bei dem die Variationspunkte durch eine Transformation (T) 
nur in Abhangigkeit von Trans format ionsregeln TR in einen in 
der Meta-Auszeichnungssprache formulierten zweiten Code 
(CodeML*) umgewandelt werden und 

- bei dem dieser zweite Code in der veranderten Software 
(SW*) entweder einen Variationspunkt VP* bildet oder durch 
einen Konverter (RCONV) in einen Quellcode SC* und mittels 
eines Kompilers (COMP) in einen BinSrcode bzw. ByteCode B* 
tlberftlhrt wird, und sich die erste und die zweite Software in 
ihrem Programmablauf bzw. Programminhalt unterscheiden. 

2. Verfahren nach Anspruch 1, 

bei dem die erste Software mindestens einen Variationspunkt 
VP enthalt und die Trans format ionsregeln TR mindestens einen 
Modifikationsregel fUr einen Variationspunkt aufweisen. 

3. Verfahren nach Anspruch 1 oder 2, 

bei dem der Modifikationsregel ein Update auf eine neuere 
Softwareversion bzw. ein Patching anstoBt. 

4. Verfahren nach Anspruch 1 oder 2, 

bei dem die Modifikation mindestens eines Variationspunktes 
VP durch die Transformation T und die Kompilierung von VP* 
speziell zur Laufzeit anstatt davor erfolgt. 

5. Verfahren nach einem der vorhergehenden AnsprUche, 

bei dem die Programmiersprache des Quellcodes Java und die 
Meta-Auszeichnungssprache der Variationspunkte XML ist und 
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bei dem die Transformation und die Regelbeschreibung mittels 
XSLT und XSL erfolgt. 

6. Anordntmg zur kundenseitigen Anpassung von Software, 

- bei der ein erster Konverter (CONV) und Kompiler (COMP) 
derart vorhanden ist, dass eine erste Software (SW) in einer 
Meta-Auszeichnungssprache formulierte Variationspunkte VP und 
kompilierte Bestandteile B umgewandelt wird, 

- bei der ein Prozessor derart vorhanden ist, dass diese 
Variationtspunkte VP durch eine Transformation T nur in 
Abhangigkeit von Trans formationsregeln TR in einen in der 
Meta-Auszeichnungs3prache formulierten zweiten Code (CodeML*) 
bzw. VP* umgewandelt werden und 

- bei der ein zweiter Konverter (RCONV) bzw. Kompiler (COMP) 
derart vorhanden ist, das dieser zweite Code in einer zweiten 
Software (SW*) zusStzlich als SC* bzw. B* enthalten sein 
kann, wobei sich die erste und die zweite Software in ihrem 
Programminhalt und Programmablauf unterscheiden. 
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Zusainiaenf assxing 

Verfahren und Anordnung zur kundenseitigen Anpassung von 
Software 

Die Erfindung besteht im Wesentlichen darin, dass eine erste 
Software mit Variationspunkten VP ausgestattet werden kann, 
welche in eine Meta-Auszeichnungssprache formuliert sind, und 
kundenseitig durch eine Transformation nur in Abhangigkeit 
von Transformationsregeln TR, die Modif izierungsregeln far 
die Variationspunkte enthalten, in eine zweite Software 
umgewandelt werden kann, welche die Variationspunkte VP 
entweder in modif izierter Form VP* oder in kompilierter Form 
VPB* enthait. Die zweite umgewandelt Software unterscheidet 
sich dabei von der ersten in ihrem Programmablauf bzw. 
Programminhalt . 



Zeichnung 1 
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